ADDITIONAL SYSTEM INFORMATION : OS : Same behaviour on window7 and Windows10 JAVA : 1.8u202

A DESCRIPTION OF THE PROBLEM : There are two scenario’s Scenario 1: In windows 7 or 10, When I have two java installed (1.8u202 32 bit and 1.8u202 64 bit). My application(Swing application) was launched with 64 bit java is running fine for months. Scenario 2: In windows 7 or 10, When I have only 1.8u202 64 bit java installed .My application(Swing application) was launched with 64 bit java crashes after 2 days of running .Reason of crash is Native memory allocation (malloc) failed to allocate 32744 bytes for ChunkPool::allocate.

Java arguments :-Xms333m -Xmx1332m -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass -XX:+HeapDumpOnOutOfMemoryError

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : Run the application which load around 14000 classes in metaspace . Compare the results when you have 32 and 64 bit java installed with when you have only 64 bit java installed.

EXPECTED VERSUS ACTUAL BEHAVIOR : EXPECTED — Ideally when the application is launched using the 64 bit java even though you have both 32 and 64 bit java installed should behave same like application launched using the 64 bit java when you have 64 bit java installed.

Why crash is only happening when you have 64 bit java installed only .

Is there any difference in memory model or memory referencing when you have both 32 and 64 bit java installed . ACTUAL — I saw the crash of my application when you have only 64 bit java installed in the system. # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (malloc) failed to allocate 32744 bytes for ChunkPool::allocate # Possible reasons: # The system is out of physical RAM or swap space # The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap # Possible solutions: # Reduce memory load on the system # Increase physical memory or swap space # Check if swap backing store is full # Decrease Java heap size (-Xmx/-Xms) # Decrease number of Java threads # Decrease Java thread stack sizes (-Xss) # Set larger code cache with -XX:ReservedCodeCacheSize= # JVM is running with Unscaled Compressed Oops mode in which the Java heap is # placed in the first 4GB address space. The Java Heap base address is the # maximum limit for the native heap growth. Please use -XX:HeapBaseMinAddress # to set the Java Heap base and to place the Java Heap above 4GB virtual address. # This output file may be truncated or incomplete. # # Out of Memory Error (allocation.cpp:272), pid=6580, tid=0x0000000000001860 # # JRE version: Java(TM) SE Runtime Environment (8.0_202-b08) (build 1.8.0_202-b08) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode windows-amd64 compressed oops) # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows #

————— T H R E A D —————

Current thread (0x0000000016202000): JavaThread «C2 CompilerThread0» daemon [_thread_in_native, id=6240, stack(0x0000000017860000,0x0000000017960000)]

Stack: [0x0000000017860000,0x0000000017960000] [error occurred during error reporting (printing stack bounds), id 0xc0000005]

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

FREQUENCY : always